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5 La presente. invention concerne un procede de proposition d'un 

service fourni par un ordinateur serveur dans un reseau de communication. 

; Elle concerne egalement un procede de test d'acces a un service par 
un ordinateur client et un procede de validation d'un message repu par un 
ordinateur intermediate du reseau de communication. 
10 Au sein d'un reseau de communication informatique du type Internet, 

des ordinateurs serveurs offrent de plus en plus souvent des services a d'autres 
ordinateurs, appeles ordinateurs clients, de ce reseau de communication. 

En pratique, I'ordinateur client envoie des donnees a I'ordinateur 
serveur qui les traite et retourne un resultat. ^ 
15 De tels services sont appeles services Web. 

Un service Web est un service identifie par une URI et accessible via 
XML et un protocole internet. 

Du fait de Taugmentation de ces services disponibles sur un reseau 
de communication, les protocoles d'echange de donnees entre des ordinatejjrs 
20 sont frequemment standardises. - ; 

Ainsi, le protocole SOAP est un protocole permettant d'echanger des 
informations structurees au-dessus du reseau Internet. 

Selon ce protocole SOAP, les informations echangees sont 
^ structurees au moyen de balises XML (acronyme du terme anglais "extended 
25 vMarkup Language"). 

NX La norme SOAP definit la structure generale des messages 
echahges ainsi que les traitements devant etre realises par un ordinateur 
envoyant ou recevant des messages SOAP. 

Ainsi, lors de I'execution d*un service Web, un ou plusieurs 
30 messages comprenant des donnees en format XML sont echanges sur le 
reseau de communication. 
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Le protocole SOAP est un protocole extensible, c'est-a-dire que la 
norme ne definit que le cceur du protocole, des fonctionnalites supplementaires 
pouvant etre ajoutees a ce protocole. 

Ces fonctionnalites supplementaires sont appelees "features". La 
5 norme SOAP version 1.2 propose une convention pour decrire ces 
fonctionnalites supplementaires, cette convention reposant sur I'utilisation de 
proprietes associees a chaque fonctionnalite. 

On trouvera une description de la norme SOAP 1.2 a I'adresse 
electronique suivante : 
10 http://www. w3.ora/TR/2002/WD-soap1 2-part1 -20020626/ 

En particulier, chaque propriete est decrite par son nom et par son 
type de donnees. 

La description de chaque fonctionnalite comprend, outre les 
proprietes, un modele decrivant comment ces proprietes sont utilisees lors de la 
15 mise en ceuvre de cette fonctionnalite. 

Par ailleurs, on connait un langage de description d'un service 
informatique WSDL (acronyme du terme anglais "Web Service Description 
Language") qui est particulierement bien adapte a decrire un service sur un 
reseau de communication. 

20 Ce langage WSDL est lui-meme une application du langage de 

balisage XML. 

On trouvera une description du langage WSDL 1.1 sur le site 
informatique a I'adresse http://www.w3.orq/TR/2001/NOTE-wsdl-20010315 

Un document electronique de description d'un service en langage 
25 WSDL comporte generalement deux parties. Une premiere partie, appelee 
"partie abstraite" est adaptee a decrire les messages echanges entre ordinateur 
du reseau de communication lors de la fourniture d'un service. 

En particulier, cette premiere partie permet de definir le type de 
donnees echangees, le type de message utilise lors de I'execution du service, 
30 ainsi que les operations mises en ceuvre, definies par les messages qui sont 
echanges lors de I'execution du service. 
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Le document de description d'un service WSDL comporte egalement 
une seconde partie adaptee a definir des informations relatives a la 
transmission des messages sur le reseau de communication. 

Cette deuxieme partie, appelee "partie concrete' 1 precise notamment 
5 via un couplage (binding) le protocole de communication qui est effectivement 
utilise pour le transfert des messages, ainsi que le format dans lequel les 
donnees seront representees pour leur communication au sein du reseau de 
communication. 

Ainsi les services proposes sur Internet echangent principalement 
10 des donnees XML dont le type est connu a I'avance, par exempie au travers 
d'une description d'un service tel qu'un document WSDL. 

Par ailleurs, de nombreux outils permettent de manipuler . des 
donnees XML, c'est-a-dire de produire des donnees XML, de les transformer ou 
encore d'utiliser ces donnees XML. * *V 

15 On connaTt ainsi up langage de transformation de documents XML, 

du type d'un script XSL (acronyme du terme anglais "extensible Stylesheet 
Language") defini par la norme X3C. u 

En pratique, une unite de traitement XSL prend en entree* un 
document ecrit en langage de balisage XML et un document XSL. Ce dernier 
20 comporte un ensemble de regies de transformation qui va permettre-la 
generation d'un nouveau document qui peut etre soit au format XML ou dans un 
, format texte. La norme XSL est elle-meme basee sur la norme XML. 

De meme, on connaTt un modele d'objet de document (en anglais 
^ Document Object Model ou DOM) qui consiste en une interface ou API (neutre 
25 \au point de vue du langage de programmation) qui , permet/ £ des 
programmes/scripts d'acceder a et modifier un document XML. L'inferface DOM 
est notamment supporte par differents langages de script tel que JavaScript. 
Outre JavaScript, d'autres langages, tels que Perl ou Python permettent la 
manipulation de documents XML via rinterface DOM. 
30 Les differents outils de traitement permettant de mettre en oeuvre ces 

scripts de traitement de donnees XML sont de plus en plus souvent integres 
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aux terminaux d'un reseau de communication, au niveau d'un client ou d'un 
serveur. 

Or, les capacites de manipulation de donnees XML sont differentes 
d'un terminal a un autre. 
5 • Par ailleurs, les traitements des donnees XML peuvent etre effectues 

a differents moments, et notamment par un ordinateur client avant qu'il n'envoie 
les donnees XML, par un ordinateur serveur avant qu'il n'utilise les donnees 
XML, par un ordinateur serveur avant qu'il n'envoie les donnees XML ou par un 
ordinateur client avant qu'il n'utilise les donnees XML. 
1 0 On distingue ainsi des types principaux de traitements, le pre- 

traitement de donnees en format XML, qui aura lieu a la reception des donnees 
XML, avant leur utilisation, et le post-traitemerit de donnees qui prend place 
apres ('utilisation de donnees XML, avant leur envoi. 

Des lors, il est interessant sur un tel reseau de communication qu'un 
1 5 ordinateur client connaisse quel type de traitement un ordinateur serveur offre. 

Par ailleurs, certains serveurs exigent Integration de certains outils 
de traitement au niveau des ordinateurs client. 

Actuellement, il n'est pas possible de decrire sur le reseau de 
communication le type de traitement (pre-traitement ou post-traitement) 
20 propose par i'un ou I'autre des terminaux du reseau de communication. 

On connaTt certains reseaux dans lesquels des traitements sont 
definis et supportes par un ordinateur serveur de maniere predefinie, sans que 
d'autres types de traitement puissent etre ajoutes de maniere extensive. 

On connait egalement des bases de donnees specifiques qui 
25 supportent un traitement XSL. Dans ce cas, un ordinateur client peut envoyer 
une requete pour un document dans lequel un script XSL est inclus. 

Le script XSL est utilise pour transformer les documents identifies 
dans la base de donnees avant leur transfer! a I'ordinateur client. Un tel 
systeme est cependant limite a une interaction entre un ordinateur client et une 
30 base de donnees specifique pour laquelle I'ordinateur client sait que I'outil de 
traitement XSL sera supporte. 
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La presente invention a ainsi pour but de resoudre les inconvenients 
precites et de proposer un systeme dans lequel il est possible de definir sur le 
reseau de communication les traitements a effectuer qui produiront ou 
utiliseront des donnees en format XML d'un message. 
5 A cet effet, la presente invention vise un procede de proposition d'un 

service fourni par un ordinateur seryeur dans un reseau de communication. 

; ' Ce procede comprend une etape d'envoi d'un document de 
description d'un service comprenant une description d'une fonctionnalite mise 
- en oeuvre lors d'un pre-traitement ou d'un post-traitement de donnees en format 
10 XML d'un message echange lors de I'execution du service sur le reseau de 
communication. 

La presente invention permet ainsi de definir au travers d'un 
document de description d'un service du type WSDL directement les 
traitements qui peuvent etre appliques aux donnees en format XML echangees 
15 lors de la mise en oeuvre du service. , *r 

Grace a la definition d'une fonctionnalite, du type d'une fonctionnalite 
("feature") telle que definie dans la norme SOAP, il est possible de decrire et 
d'utiliser cette fonctionnalite dans le document de description d'un service. - ^ 

^utilisation d'une telle fonctionnalite permet d'ajouter sans limitation 
20 differents traitements pouvant etre mis en oeuvre en differents terminaux du 
reseau de communication. 

Grace a integration de cette fonctionnalite dans un document de 
description d'un service du type WSDL, il est possible de definir et d'informer 
s \ les differents terminaux du reseau de communication de Texisterice de ces 
25 traitements dans le reseau. . \, .// 

K- Selon une caracteristique preferee de Tinventidn; cette fonctionnalite 
definit les traitements adaptes a produire ou utiliser les donnees en format XML 
definies dans une premiere partie abstraite de document de description d'un 
service. La fonctionnalite de traitement peut ainsi etre offerte pour I'ensemble 
30 des protocoles disponibles. 
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II est ainsi possible de specifier des traitements applicables a des 
donnees XML dont le type est connu et defini au travers d'une description 
comme un document WSDL. 

De preference, cette fonctionnalite decrivant un traitement adapte a 
5 manipuler (utiliser ou produire) des donnees en format XML abstraites, sa 
description est de preference associee a ces donnees abstraites a I'interieur du 
document de description d'un service. 

Selon une caracteristique avantageuse de I'invention, le pre- 
traitement ou le post-traitement des donnees est mis en ceuvre via un langage 
10 de script. 

Selon un autre mode de realisation de I'invention, qui permet 
avantageusement I'utilisation de la fonctionnalite pour tout type de protocole, la 
fonctionnalite est definie comme une donnee en format XML dans une premiere 
partie abstraite du document de description d'un service. 
15 Dar >s ce mode de realisation, cette donnee en format XML 

definissant la fonctionnalite est de preference encodee dans une seconde partie 
concrete du document de description d'un service. 

Ainsi, la fonctionnalite est proposee au niveau abstrait du document 
WSDL. Dans ce cas, le traitement ajoute se traduit comme une donnee XML 
20 (optionnelle ou obligatoire) ajoutee au message. Cette donnee XML est ensuite 
encodee au niveau de la partie concrete du document WSDL comme tout autre 
partie du message abstrait. 

Ainsi, la fonctionnalite est offerte a tous les protocoles. 
Selon une autre caracteristique preferee de I'invention, la description 
25 de la fonctionnalite comprend une liste de proprietes supportees par la 
fonctionnalite, les proprietes definissant au moins respectivement : 

le nceud du reseau de communication adapte a executer le 

traitement ; et 

le type de traitement. 

30 Cette fonctionnalite peut comporter ainsi differentes informations 

definies sous la forme de proprietes. 
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II est notamment possible de definir le type de traitement et Tendroit 
du reseau de communication adapte a mettre en oeuvre ce traitement. 

Cette fonctionnalite peut comprendre une propriete adaptee a 
specifier si le traitement est effectue a renvoi ou a la reception du message. 
5 De preference, cette fonctionnalite comprend en outre une propriete 

adaptee a specifier le message ou un ensemble de messages sur lequel 
s'applique le traitement. 

; De meme, cette fonctionnalite comprend de preference une propriete 

adaptee a definir les donnees produites ou utilisees par le traitement, et 
10 eventuellement le type de ces donnees. 

II est ainsi possible grace au type de ces donnees definies dans le 
document de description WSDL de valider avant et apres traitement les 
donnees generees en determinant si le type de ces donnees correspond 
effectivement au type predefini au travers de la description de la fonctionnalite. 
15 Selon une autre caracteristique preferee de Tinvention, cette 

fonctionnalite comprend en outre une propriete adaptee a specifier siv le 
traitement est effectue a renvoi ou a la reception du message, afinr de 
determiner s'il s f agit d'un post-traitement ou d'un pre-traitement des donnees'en 
format XML du message. '& 
20 Selon une caracteristique avantageuse, la description de^ft la 

fonctionnalite comprend egalement une propriete adaptee a specifier si le 
traitement a effectuer est obligatoire ou optionnel. 

En pratique, pour au moins ' une propriete suppprtee par la 
fonctionnalite, la description de cette fonctionnalite comprend une liste de 
25 Vvaleurs attribuables a cette propriete. , ;/ 

On peut ainsi utiliser le mecanisme defini par la norme SOAP pour 
decrire les differentes proprietes de cette fonctionnalite. yjy 

Selon un autre aspect de I'invention, elle concerne un procede de 
test d'acces a un service par un ordinateur client d'un reseau de 
30 communication, a partir d'un document de description d T un service. 

Ce procede de test d'acces comprend les etapes suivantes : 
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extraction d'une description d'une fonctionnalite mise en oeuvre 
lors d'un pre-traitement ou du post-traitement de donnees en format XML d'un 
message echange lors de I'execution du service sur ie reseau de 
communication ; 

5 - lecture de la valeur associee a une propriete adaptee a specifier 

le nceud du reseau de communication adapte a executer le traitement ; 

lecture de la valeur d'une propriete adaptee a specifier si le 
traitement est obligatoire ou optionnel ; et 

verification si le traitement est supporte par I'ordinateur client du 
10 reseau de communication lorsque le traitement est obligatoire et doit etre 
execute par I'ordinateur client du reseau de communication. 

II est ainsi possible a I'ordinateur client de tester s r il est adapte a 
inter-agir avec un service propose par un ordinateur serveur. 

Selon un troisieme aspect de ('invention, elle concerne un procede 
15 de validation d'un message regu par un ordinateur intermediaire du reseau de 
communication, a partir d'un document de description d'un service comprenant 
une description d'une fonctionnalite mise en oeuvre lors d'un pre-traitement ou 
du post-traitement de donnees en format XML du message echange lors de 
I'execution de ce service sur le reseau de communication. 
20 Ce procede de validation comprend les etapes suivantes : 

extraction d'un traitement dans le message regu ; 
acquisition d'au moins une valeur imperative associee a une 
propriete du traitement ; et 

verification si la valeur imperative est incluse dans une liste de 
25 valeurs attribuables a une propriete supportee par la fonctionnalite decrite dans 
le document de description d'un service. 

II est ainsi possible a partir d'un message et des valeurs des 
proprietes associees a chaque traitement inclus dans le message, de verifier s'il 
correspond a la description du traitement tel que decrit dans la fonctionnalite du 
30 , document de description d'un service. 

De preference, lors de cette validation du message par un ordinateur 
intermediaire, le procede comprend une etape de lecture de la valeur associee 
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a une propriete adaptee a specifier si le traitement est execute avant ou apres 
['envoi du message et une etape d'execution de ce traitement lorsque la valeur 
est adaptee a specifier que le traitement doit etre execute avant renvoi du 
message. 

5 La presents invention concerne egalement un dispositif de 

proposition d'un service fourni par un ordinateur serveur dans un reseau de 
communication. 

Ce dispositif de proposition d'un service comprend des moyens 
d'envoi d'un document de description d'un service coniprenant une description 
10 d'une fonctionnalite mise en oeuvre lors d'un pre-traitement ou d'un post- 
traitement de donnees en format XML d'un message echange lors de 
Texecution de ce service sur le reseau de communication. 

Elle concerne egalement un dispositif de test d'acces a un service 
par un ordinateur client d'un reseau de communication, a partir d'un document 
15 de description d'un service, comprenant : 

des moyens d'extraction d'une description d'une fonctionnalite 
mise en oeuvre lors d'un pre-traitement ou du post-traitement de donnees en 
format XML d'un message echange lors de ('execution du service sur le resteau 
de communication ; 

20 - des moyens de lecture de la valeur associee a une propriete 

adaptee a specifier le terminal du reseau de communication adapte a executer 
le traitement ; . 

- des moyens de lecture de la valeur d'une propriete adaptee a 
, \ specifier si le traitement est obligatoire ou optionnel ; et ; // 

25 \\ - des moyens de verification adaptes a verifier si le traitement est 

supporte par I'ordinateur client du reseau de communication lorsque ce 
traitement est obligatoire et doit etre execute par Tordinateur client du reseau de 
communication. . ... * > y 

La presente invention concerne egalement un dispositif de validation 
30 d'un message re<?u par un ordinateur intermediate du reseau de 
communication, a partir d'un document de description d'un service comprenant 
une description d'une fonctionnalite mise en oeuvre lors d'un pre-traitement ou 
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du post-traitement de donnees en format XML du message echange lors de 
I'execution d'un service sur le reseau de communication. 
Ce dispositif de validation comprend : 

des moyens detraction d'un traitement dans un message re9U ; 
5 -■ des moyens d'acquisition d'au moins une valeur imperative 

associee a une propriete du traitement ; et 

des moyens de verification adaptes a verifier si la valeur 
imperative est incluse dans une liste de valeurs attribuables a une propriete 
supportee par la fonctionnalite decrite dans le document de description d'un 
10 service. 

Ces dispositifs de proposition d'un service, de test d'acces et de 
validation d'un message re9u presentent des caracteristiques et avantages 
analogues a ceux des procedes qu'ils mettent en oeuvre. 

Par ailleurs, la presente invention concerne un ordinateur comportant 
15 un dispositif de proposition d'un service ou un dispositif de test d'acces ou un 
dispositif de validation d'un message conformes a I'invention. 

Elle vise tout particulierement un ordinateur serveur d'un reseau de 
communication comprenant des moyens adaptes a mettre en oeuvre le precede 
de proposition d'un service conforme a I'invention. 
20 Correlativement, elle vise un ordinateur client d'un reseau de 

communication comprenant des moyens adaptes a mettre en oeuvre le procede 
de test d'acces conforme a I'invention. 

La presente invention vise egalement un ordinateur d'un reseau de 
communication comprenant des moyens adaptes a mettre en osuvre le procede 
25 de validation d'un message conforme a I'invention. 

Plus generalement, la presente invention concerne un reseau de 
communication comprenant des moyens adaptes a mettre en oeuvre le procede 
de proposition, d'un service et/ou le procede de test d'acces et/ou le procede de 
validation d'un message conformes a I'invention. 
30 E| le vise par ailleurs un moyen de stockage d'informations, 

eventuellement totalement amovible, lisible par un systeme informatique, 
comprenant des instructions pour un programme informatique adaptees a 
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mettre en ceuyre le procede de proposition d'un service et/ou le procede de test 
d'acces et/ou le procede de validation d'un message conforme a I'invention, 
lorsque ce programme est charge et execute par le systeme informatique. 

Enfin, elle concerne un programme d'ordinateur lisible par un 
microprocesseur comprenant des portions de code logiciel adaptees a mettre 
en ceuvre le procede de proposition d'un service et/ou le procede de test 
d'acces et/ou le procede de validation d'un message conformes a I'invention, 
lorsque ce programme d'ordinateur est charge et execute par le 
-microprpeesseur. 

Les ordinateurs, I'ordinateur serveur, I'ordinateur client, le reseau de 
communication, le moyen de stockage d'informations et programme 
d'ordinateur presentent des caracteristiques et avantages analogues aux 
prdcedes qu'ils mettent en ceuvre. 

D'autres particularites et avantages de I'invention apparaTtront 
encore dans la description ci-apres. i 

Aux dessins annexes, donnes a titre d'exemples non limitatifs : 

la figure 1 est un algorithme illustrant un procede de proposition 
d'un service conforme a rinvention ; ;j 

la figure 2 est un algorithme illustrant un procede de test d'acges 
a un service conforme a un mode de realisation de rinvention ; , 

- la figure 3 est un algorithme illustrant un procede de validation 
d'un message regu par un ordinateur conforme a un mode de realisation de 
I'invention ; \ v . ; . 

v - la figure 4 est un algorithme illustrant i v execution d'un message 
incluant un traitement ; et 4 

v * la .figure 5 est un schema bloc illustrant un dispositif adapte a 
mettre en oeuvre rinvention. > 

On va decrire tout d'abord en reference a la figure 1 un procede de 
proposition d'un service fourni par un ^ordinateur serveur dans un reseau de 
communication. 

Dans un reseau d'ordinateur tel qu'lnternet, des serveurs fournissent 
des donnees sous forme de documents a des ordinateurs clients. , 
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Tres frequemment, ces ordinateurs serveurs fournissent egalement 
des services, appeles services Web, permettant a un ordinateur client d'envoyer 
des donnees au serveur qui les traite et retourne un resultat. 

En pratique, lorsqu'un ordinateur client d'un reseau de 
5 communication souhaite utiliser les services fournis par un ordinateur serveur, il 
envoie un message afin de requerir une description des services fournis par cet 
ordinateur serveur. 

A la reception E10 d'une telle requete de description, le procede de 
proposition de services comprend une etape d'envoi E11 d'un document de 
10 description d'un service. 

Dans la suite de la description, et de maniere non limitative, on 
considerera que ce document de description d'un service utilise le langage 
WSDL (acronyme du terme anglais "Web Service Description Language"), qui 
est un langage permettant de decrire des services Web. 
15 Ce langage WSDL est un langage XML perfectionne, permettant a 

I'aide de balises XML de decrire un service Web. 

Un document WSDL contient principalement deux parties. Une 
premiere partie, appelee partie abstraite, decrit de maniere abstraite les 
messages qui sont echanges entre ordinateurs du reseau de communication 
20 lors de la mise en oeuvre du service. Une seconde partie est adaptee a 
comporter les informations concretes, definissant la transmission des messages 
sur le reseau de communication. 

La premiere partie est elle-meme divisee en trois sous-parties. 

La premiere sous-partie de cette premiere partie contient des 
25 declarations de types, permettant de decrire la structure abstraite des 
messages. Ces types sont ensuite references dans la deuxieme sous-partie de 
la premiere partie du document WSDL. 

La declaration de ces types est generalement realisee au moyen de 
balises <types>...</types>. 
30 Cette declaration de types est bien connue dans les documents 

ecrits en langage XML et il n'est pas necessaire pour la comprehension de 
('invention de decrire plus avant les types utilises. 
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Laseconde sous-partie de la premiere partie du document contient 
des declarations de messages elementaires. 

Elle definit ainsi les messages qui seront echanges entre les 
ordinateurs lors de la mise en oeuvre du service, sans en decrire precisement le 
5 contenu ou Tenchamement. 

Elle consiste a definir de maniere abstraite et de donner le type d'une 
donnee transmise (entree ou sortie). / *'''-- v v 

v .y ' A titre d'exemple, et uniquement pour faciliter la comprehension de la 
presente invention, les messages suivants peuvent etre definis, sans lien entre 
10 eux : % 

a) un premier message permet de transmettre le nom d'une action : 

<message name= "GetStockQuote Input "> ^ 

<part name="Name" type=" string" /> \ . 

</message> 

15 b) un second message permet de transmettre le prix associe a une 

action : 

<message name="GetStockQuoteOutput"> 
<part name="Pric.e" type==" float " /> 
[ ^ </message> \ / t r '. ■ 

20 Une troisieme sous-partie de la premiere partie du document WSDL 

permet de regrouper les messages elementaires ainsi definis dans lesVdeux 

premieres sous-parties en operations logiques. 

Une operation peut etre consideree comme un service elementaire, 

ce dernier etant lui-meme implante par un ou plusieurs messages. , 

25 Elle est ainsi definie par ses entrees et sorties, c'est-a-dire par les 

x messages qu'elle echange. < x \O c ' ^ 

Par exempie, une operation retournant la valeur d'une action lors de 



la reception du nom de cette action peut etre definie comme suit : 



<operation name="GetStockQuote"> - - • ' /4 -^ 

30 <Iriput message="tns: Gets to c kQuofce Inpu t" / > *" 

<output message="tns : GetStockQuoteOutput " /> ^ 
< /operations ... 

Bien evidemment des formes plus, elaborees d'operation, constitue 

d'un ensemble complexe d'echanges de messages, pourraient etre decrites 

35 dans ce langage. 



1er depot 



14 



Cette premiere partie du document WSDL permet ainsi de definir le 
type, le contenu et I'ordonnancement des messages echanges entre 
ordinateurs du reseau lors la mise en oeuvre d'un service propose par un 
ordinateur serveur. 

Le document WSDL comprend en outre, comme explique 
precedemment, une seconde partie concrete qui permet de preciser quel 
protocole est effectivement utilise pour transmettre les messages et quel 
encodage ou format de representation est mis en ceuvre pour representer ces 
donnees sous une forme adaptee au reseau de communication. 

Cette seconde partie correspond ainsi a un couplage (binding) 
consistant a specifier un protocole concret et un format de donnees pour une 
operation definie dans la premiere partie du document WSDL. 

Conformement a invention, le document de description d'un service 
comprend la description d'une fonctionnalite mise en oeuvre lors d'un pre- 
traitement ou d'un post-traitement de donnees en format XML d'un message 
echange lors de Pexecution du service sur le reseau de communication. 

Cette fonctionnalite permet ainsi de definir des traitements a 
effectuer sur un message. 

II s'agit en particulier de traitements qui utilisent ou produisent des 
donnees en format XML qui sont definies dans la partie abstraite du document 
de description d'un service WSDL. 

On notera cependant qu'un traitement peut combiner plusieurs 
traitements. 

Cette description de fonctionnalite consiste a definir une 
fonctionnalite par une liste de proprietes supportees par cette fonctionnalite. 

II s'agit alors de donner une description, par exemple dans un 
langage de balisage du type XML, de la fonctionnalite en decrivant les 
proprietes associees a cette fonctionnalite. Ces elements ou fonctionnalites 
ainsi definis, ils peuvent etre utilises pour etre inclus dans une description de 
service du type d'un document WSDL. 
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Onobtient ainsi un document de description d'un service ecrit dans 
un langage WSDL perfectionne, permettant de decrire directement dans ce 
document les traitements a effectuer sur un message. 

Les proprietes de cette fonctionnalite permettent de determiner en 
5 particulier sur quel message ou sur quel ensemble de message le traitement 
s'applique ; le moment auquel le traitement est effectue, et notamment a renvoi 
ou a la reception du message par un ordinateur ; quelles donnees du message 
le traitement utilise ou genere et le type de donnees ainsi generees. 

Lorsque le traitement est mis en oeuvre via un langage de script, il 
10 est necessaire de definir Regalement les scripts possibles pour ^execution de ce 
traitement. ; \ 

En outre, il est avantageux qu'une propriete permette de specifier si 
le traitement a effectuer est obligatoire, ou optionnel, ou encore negociable. 

On va donner ci-apres un premier exemple de description -en 
1 5 langage XML d'une telle fonctionnalite de traitement. - 

La description XML d'une fonctionnalite est ainsi encapsulee dans un 
element XML. On considere ici de maniere non limitative que la fonctionnalite 
est du type d'un element ("feature") tel que defini par la norme SOAP. : 

Cet element comporte un attribut obligatoire "name" permettantide 
20 donner un nom au traitement et de referenced ulterieurement la description de 
cette fonctionnalite. 

En outre, la liste des proprietes supportees par cette fonctionnalite 
est inseree aj'interieur de ('element. Chaque propriete est definie par un 
\\ element que I'on nomme "property". Cet element a un attribut obligatoire 
25 "name". Pour chaque propriete, la description de cette fonctionnalite cprinprend 
uhevliste de valeurs attribuables a cette propriete. 1 > s , > 

V Ainsi, a titre d'exemple, la fonctionnalite "process, feature" peut etre 

' ' ' > " N ' h ' :' f ' 

decrite de la fafon suivante, sous la forme de schema XML : 

<feature name=" Proce-ss Feature" > ' . •• ' 

<property name= "process" type="ProcessType" /> 
<property name = " value" type=" ValueType " /> 
<property name="da ta" type=" Da taType " /> 
. <property name="rule" type="RuleT.ype" /> 

</feature> 
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<xs : complexType name="ProcessType"> 
<xs : element name="process tr > 
<xs : complexType> 

<xs .-attribute name="name" type="xs : string" /> 
<xs : attribute name="side"> 
<xs : simpleType> 

<xs : restriction base="xs : NSTOKEN"> 
<xs : enumeration value="sender M /> 
<xs : enumeration value-" receiver " /> 
</xs : restriction> 
</xs : simpleType> 
</xs : attribute> 

<xs: attribute name-"order " type="xs : inteqer " 
use="optional"/> 

<xs : attribute name="msg" type="xs : NCNAME" /> 
</xs : complexType> 
</xs : element> 
</xs : complexType> 

<xs : complexType name="ValueType"> 

<xs: element name="type" maxOccurs="unbounded n > 
<xs : complexType> 

<xs: element name=" value" minOccurs=" 0 "> 
<xs : complexType> 
<xs : choice> 

<xs:any processContents-" lax" minOccurs=" 0 " 
maxOccur s= "unbounded " /> 

<xs : element name="value " > 
<xs : complexType> 

<xs:any processContent s=" lax " 

minOccurs="0" maxOccurs= "unbounded" 
- <xs : complexType> 
</xs : element> 
</xs : choice> 
</xs : complexType> 
</xs : element> 

<xs:anyAttribute processContents="lax" minOccurs="0 " 
maxOccurs="unbounded" /> 
</ xs : complexType> 
</xs : element> 
</xs : complexType> 

<xs : complexType name=" DataType"> 
<xs: element name="data"> 
<xs : complexType> 

<xs: element name-"input" minOccurs="0"> 
<xs : cornplexType> 

<xs: attribute name="ref" use= "optional " /> 
<xs: attribute name="type" use="optional " /> 
<xs : anyAttribute processContents=" lax " 

minOccurs-"0" maxOccurs="unbounded " /> 
<xs:any processContents="lax" 

minOccurs="0" maxOccurs="unbounded" /> 
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</xs : complexType> 
</xs : element> 

<xs element name=" output 11 minOccurs=" 0 "> 
<xs : complexType> 
. <xs : attribute name="ref" type="xs : string" 
use="optional , 7> 

<xs : attribute name-" type " type="xs : string" 
use="optional"/> 

<xs : anyAttribute processContents-"lax" 

ininOccurs="0" maxOccurs="unbounded"/> 
, .v- <xs:any processContehts="iax" " v , 

syf v ~? " rairiOccurs = " 0 " 5 maxOccur s'= " unbounded " / > 

//■' ' </xs : complexType> x% 

J/ </xs : element> - . '. ' -<"' ; \\ 

</xs : complexType> v 
. : < /xs : e 1 erne n t > ' 
, </xs : complexType> ; , /■ . v x v ' ; V. 

<xs : complexType n ame = " Ru 1 e T y p e " > 
<xs: element name="rule"> - ' 
<xs : simpleContent> 

<xs : attribute name="yaliie'' type="xs : boolean" 
use="required"> v . . 

<xs : simpleContent> - 

<xs : restriction base="xs :string M > 

<xs : enumeration value="mandatory , 7> . *""..*- 
y- ,<xs : enumeration value^"optional'7> 
I </xs : restriction^ . \ 

</xs : simpleGon'tent> ,< ' 
. </xs,: attribute>. , r . . 

</xs : extensi"6n>" -1 , : ' . f-] 

</xs : simpleConteht> - ... ,. V" 

</xs.: elements *' ' (/ '' /■■ v../ / " — N - ' >>•• ';•*''••'/ / " 
</xs : complexType> : - • . 

Ainsi, dans cet exemple, la fonctionnalite "process feature" a une 
propriete, nommee "process", qui permet de definir le message cible et Tentite 
de^; traitement, c'est-a-dire le noeud du reseau de. communication adapte a 
\executer le traitement. </% \^ // 

Elle cpmporte egalement une propriete qui a pour nom "value" et qui 



permet de definir le type et la valeur du traitement. 

La fonctionnalite comporte egalement une propriete ayant pour nom 
"data" qui definit les donnees en entree et en. sortie du traitement, et notamment 
le type de donnees generees. 

En outre, une propriete "rule" permet de definir si le traitement a 
effectuer est obligatoire ou optionnel. 
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La description de chaque propriete est ainsi decrite a I'aide d'un 
langage de schema, tel que XML-schema, de telle sorte que la description de 
chaque propriete est inseree par reference dans la description de la 
fonctionnalite. 

Ainsi, dans I'exemple precedent, la propriete "process" definit le 
message sur lequel s'applique le traitement sous la forme d'un attribut ayant 
pour nom "msg". Cet attribut peut definir un message particulier, ou encore un 
ensemble de messages, par exemple I'ensemble des messages envoyes par 
un ordinateur serveur. 

Cette propriete "process" comporte egalement un attribut "side" 
permettant de definir si le traitement est effectue a I'envoi, par un emetteur, ou a 
la reception, par un recepteur du message. 

Ainsi, les valeurs qui peuvent etre pris par cet attribut "side" sont 
typiquement "sender" ou "receiver" (emetteur ou recepteur). 

line seconde propriete "value" permet de definir les valeurs qui 
peuvent etre prises par un script lors du traitement. Cette propriete permet de 
definir le type de script utilise via un element "type" comprenant un attribut 
"name". A I'interieur de cet element "type", il est possible d'ajouter des 
contraintes, comme par exemple la possibility d'utiliser certaines parties du 
langage. 

II est egalement possible de proposer le choix entre plusieurs scripts. 
Enfin, un meme traitement peut supporter plusieurs types de script ; il suffit 
alors d'ajouter dans la description autant d'elements "type" que de types de 
scripts. 

Une propriete "data" permet en outre de definir les donnees utilisees 
via un element "input" et les donnees produites via un element "output". Ces 
elements peuvent contenir un attribut "ref qui determine la partie du message. 
Dans I'exemple precedent, le type des donnees est specifie au moins en entree 
ou en sortie du traitement. 

II est ainsi possible de determiner si les donnees en entree sont 
valides, et apres execution du script, si les donnees en sortie sont valides. 
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Ce, type de donnees petit etre specifie indirectement via une 
definition abstraite du message dans un document WSDL ou bien directement 
par un attribut "type". 

Enfin, une propriete "rule" permet de definir si le traitement a 
effectuer est obligatoire ou optionnel. 

En j'absence de cette propriete, le traitement est obligatoire. 
. v > Bien que Ton ait decrit ci-dessus un exemple de. fonctionnalite 
utiljsant le protocole SOAP, permettant le traitement de donnees abstraites via 
une feature SOAP, n'importe quel type de fonctionnalite, s'appliquarit alors a 
tout autre protocole, pourrait etre decrit de la meme maniere au niveau abstrait 
d'un document de description d'un service WSDL. ^ ^ , \ % " 

Ainsi, on peut implementer une fonctionnalite de traitement au niveau , 
abstrait du document de description d'un service WSDL, en ajoutant une 
donnee XML au message, traduisant un traitement a effectuer sur des donnees. 

Cette donnee XML est ensuite eneodee (ou serialisee) au niveau de 
la seconde partie concrete du document de description d'un service WSDL 
comme tout autre partie de message abstrait. 

Ainsi, cette fonctionnalite est offerte a tout type de protocole, et par 
exemple au protocole SOAP, [au protocole HTTP ou encore au protocole BEEP 
dont une description peut- etre consultee ; a /Tadresse suivante ■ 

http://www.ietf.org/rfc/rfc3080.txt ' / A ;; V/ / ... y 

■ / / /' y , - * / 

On definit alors dans la description de cette' fonctionnalite un 

' ,• . X ' - X / / // 'V-V 

encodage par defaut dependant du protocole, tel que par exemple.: ^ 

' v s''\> - pour-HTTP, une partie message mime ; 

^ - r pour SOAP, un en-tete particulier ; et - 

- /pour BEEP, un element XML particulie&^V 

// ...... ^ // \>.\\> > 

, Ainsi il n'est pas/neees^aire, cte Specifier des donnees concretes 
dans le document Cependant si I'on souhaite specifier des informations 
concretes dans le document WSDL r on* utilise* une reference a la propriete 
concernee. 

Un exemple d'une telle reference est donnee ci-apres : 
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<portType name="fooPT"> 

<operation name= u foolOP M > 

<input message= ?f foolIVisgIn" name="in"/> 
<output message="foolMsgOut" name="out"/> 
<feature ref="ProcessFeature n mustUse= Tr false"> 
<property name=" .process"> 

<process name="XSLT_IN" side= n receiver " 
msg= n name:foolMsgIn'7> 
</property> 

<property name="http: //xsl t-f eature/value " > 

<value> 

<type name="XSLTV> 

</value> 
</property> 

<property name="data"> 
<data> 

<output ref="part : *"/> 
</'data> 
</property> 
</f eature> 
</portType> 

<binding name= " f ooSoap" type="fooPt"> 

<soap:binding transport="http: //example . com/soap/http" /> 
Operation narae="foolOP"> 
<input> 

<soap:body part="xml-datal " .../> 
<soap: header part="xml-data2 " .../> 

<soap: header part="http : //xslt-f eature/value" .../> 
</input> 
<output/> 
</operation> 
</binding> 

<binding name="fooHttp" type="f ooPt "> 

<http:binding transport="http : / /example . com/http" /> 
<operation name-"foolOP"> 
<input> 

<mime : mul tipartRelated> 
<mirne : part> 

<mime : content 

part="xitil-datal" use="literal n /> 

</mime:part> 
<raime:part> 

<mime: content part="xml-data2 " use=" literal " /> 
</mime:part> 
<mime : part> 

<mime : content 

part= n http: //xsl t-f eature/value" 
type=" text /my~op- script" /> 

</mime : part> 
</mime : mul tipartRelated> 
</input> 

<output/> " • 

</operation> 
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</binciing> , 

Ainsi, il est possible d'encoder la valeur d'une propriete abstraite au 
moyen d'un mecanisme de reference identique a celui utilise pour encoder des 
donnees abstraites des messages; " - ^ 

En, outre,' un encodage par defaut peut etre defini dans un format 



comprehensible par une machine pour d iffe ren ts> p rotoco le s? 



On revient a present au premier exemple de realisation dans lequel 

-\ X ^\ " ' - :■; ' ... ^ NX 

/la fonctionnalite est du type d'un element "feature" tel "que defini parla norme 



■■'/ soap. .\ v ^ -^--o^ 

>^ Une^fois les proprietes de la fonctionnalite definies, on peut decrire 
0 un service implementant jcette fonctionnal travers^d'un document de 

description d'un service WSDL. w i.-; t , ^ ^ \ \ \ / % 

f De preference, on integre la>d^scriptjpn de cette fonctionnalite, via 
un element "feature" place dans la partie abstraite ciu document de description 
d'un service, des lors que cette fonctionnalite est adaptee a produire ou utiliser 
5> des donnees en format XML definies da ns cette meme partie abstraite. • 

A fihterieur /de I'element "feature", les -valeurs prises >par les 
differentes proprietes sont specifiees K parrhi la liste de valeurs attribuables a 
^ chaque propriete. E^cTautr^t£rmesr donpe un 

^ensemble de valeurs; que x peut prendre chaque propriete, ^ ,fe document de 
0 description d'un service WSDL est adapte a definir un sbus-ensembie^de ces 
valeurs de propriete, c'est-a-dire a ajouter des contralntes sur les;. valeurs qiie 

""V \ \\\. y/jf ' %N // 

peuvent prendre ces proprietes. " , . ^ s x> // ' 

■ y ■:' On dpnne un exemple ci-dessous d'une utilisation de la fonctionnalite 
^ y s/- * " - x > // 

deprite preeedemment telle qu'elle peut etre incorporee dans un document de 

5 descripjion d'un service/ du type WSDL. « - r >l']) V ^ 

<portTypeCname="f ooPT"> L — ' - " ' 
<operation* % narae=^ n f oolOP"> 

<input me s s age =^V"f ..^o%M*s^g. I-n^--i^rrer€^rn " 7> 
<output message=" foolMsgbut" name="out " /> 
< feature ref =" Process Feature " mustUse=" false "> 
<property name= ,, process"> 

<process name="XSL__IN" side = n receiver " 
msg="name: f oolMs.gln" /> 
</property> 




1er depot 



22 



<property name^'Value'^ 
<value> 

<type name="XSL n /> 
</value> 
</property> 

<property narae="data"> 
<data> 

<output ref= M part : *"/> 
</data> 
</property> 
</f eature> 

<feature ref =" ProcessFeature" mustUse="true"> 
<property name= ,, proGess"> 

<process name=" JS_OUT" side="receiver ,r 
msg="name : f oolMsgOut " /> 
</property> 

<property name= ,, value"> 
<value> 

<type name-"JavaScript+DOM"> 

<! —might contain constraints on the process- 

<platform>neutral</platf orm> 

<access>internet</access> 
</type> 

</value> 

</property> 

<property name="data"> 
<data> 

<output ref-"part:partr7> 
</data> 
</property> 
</feature> 
</portType> 

<binding name- " f ooSoap" type="f ooPt "> 

<soap : binding transport="http : //example . com/http" /> 
<operation name="f oolOP"> 

<input/> 

<output/> 

<feature ref ProcessFeature" mustase=" false »> 
<property name="process"> 

<process name="XSL_OUT" side="sender" 
msg="name ; f oolMsgOut" /> 
</property>. 
<property name="value"> 
. <value> 

<type name="XSL*7> 
</value> 
</property> 

<property name= ,T output"> 
<data> 

<input ref="part : *"/> 
■ ■ </data> 
</property> 
</ feature> 
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</operation> 

<f eature ref=" Process Feature" mustUse=" f alse"> 
<property name="process"> 

<process name="PERL_IN" side="receiver" 
msg=" type : inbound" /> 
</property> 

<property name = a-l-ue^' ^r,; ;^ — - - . ^ 

<value>^<S t ' >; " r " ^ 
<>MP e 'name = " P E RL 1 1 > 
"^'< 1 i b r a r y^us.ab 1 e.=. n D'OM " / > 




' 1 



< 1 i b r a r\y« \ u nu s a b 1 e == " HT T P V /<> A i 
</va.lue> 



f ;<datW> 



/ < /prop e r t y > 
/ .c/ieature> 

^i^ing>X>/'' 



X> 



V 




Am?i, dans ^-1 -exem p le >p recede nt q u at re < Nuti I is atio n s de \la 



/ fonctionnalite sont illustrees ; \\\ . ^ N\ 

// / ■ ^ : j £J{ ^ \\\ f x V" 

V y / , 1) Le premier^traitement a un client d'inclure dans\ 

sa requete un script XSL J^Eyp^^ qui va >£tre execute;au 

niveati du service (side= M re^eiver"f et .produira les donhees telles^que 

: ; ' ? _ " ■ I -\\\ 

dernandees parfi^sewip^ est option nel\(mus t Us 44= '\ f al s e ; "), \et 

s'applique sur i urie ou /plijsi^urs parties/ 



■\ mesjsage<foo1 Msg In' (rns^rime : fdolMsglri^V^ ] !$\ _ j / I 
^ \ \\\Ainsh il • est possible' pour un hceud ihtSrmediaire /d'un reseau de 
^communication d/ajouter up script >^SL a^un message et^d-ehvoyer celuPci a un/ 

recepteuhfinal qui executera le script, puis traitera la requite/ C% // 

WX /'// // 

On,diminue ainsi la charge de travail d'un-nceud intermediaire qui/n'a 



pas J^esoin d'impldq^nt^^Jangage de^crip^jcHe^script XSL^ 

^/^"2) N Le deuxteTrie -irait^e'nf^^QOT oblige un.clien^/supporfer les 
"sieqpts JavaScript dans les messages de retour ; 

3) Le trpisierne7traitement XSL\T20 N UT; propose au^elient de fournir 





un script XSLJT^ui sera applique^surle message^d^etow , et 

4) L^^ffiie^ au client d'ajouter des 

scripts PERL dans tous les messages repus . par le service 
(msg="type: inbound"). Le traitement peut utiliser les fonctionnalites DOM 
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(<library usable="DOM"/>) de PERL mais ne doit pas utiliser les 
fonctionnalites HTTP (<library unusable="HTTP" />). 

II est ainsi possible de decrire des traitements appliques a differents 

messages echanges lors de la mise en oeuvre d'un service Web sur un reseau 

de communication. 

On va decrire a present en reference a la figure 2 un precede de test 
d'acces a un service a partir d'un document de description d'un service tel que 
decrit precedemment. 

Ce procede de test d'acces permet a un ordinateur client de verifier 
s'il est capable d'interagir avec un service propose par un ordinateur serveur du 
reseau de communication, a la reception d'un document de description d'un 
service du type WSDL tel que decrit precedemment. 

Pour verifier cet acces, I'ordinateur client est adapte a tester 
differentes choses, et en particulier les protocoles utilisables pour executer le 
service. 

En particulier, et on se limitera dans la description ci-apres a ce 
point, I'ordinateur client est adapte a verifier s'il est adapte a implementer la 
fonctionnalite de description d'un pre-traitement ou d'un post-traitement des 
donnees, et s'il est en mesure d'effectuer chaque traitement demande. 

En particulier, I'ordinateur client verifiera le type de script propose 
pour la mise en oeuvre du traitement, via la description de la propriete "value" 
decrite precedemment. 

Une premiere etape de lecture E21 est mise en oeuvre pour la 
lecture du document WSDL adapte a decrire le service. 

Une etape de selection E22 est adaptee a selectionner une operation 
decrite dans le document WSDL, e'est-a-dire une suite de messages echanges 
lors de ('execution d'un service sur le reseau de communication. 

Pour cette operation, une etape de test E23 est adaptee a verifier s'il 
existe un traitement decrit associe a cette operation. 

En pratique, une etape detraction de la description de la 
fonctionnalite est mise en oeuvre. 



1er depot 



25 



Si eucun traitement n'est decrit, une reponse est adressee dans une 
etape de reponse E27 afin d'indiquer que I'acces a I'operation est possible pour 
I'ordinateur client. 

Sinon, une etape de test E24 permet de verifier si le traitement est 
obligatoire et dj^^err^Tecute-^ client du reseau de 

communication? 



^XEn pratique $nej%p>[|re lentil re^perihetrde lire ur*e>aleur associee 




a/la proprieteA^pn0cess ,v ~ adaptee a specifier ¥,fficeud duXreseau de 



,eommunfcation devant executerlfj^itement. 



Une ^etap^d^lectCa ; ed'e ]a~valeur- de^propriete^r3e''^perm'ettant 
de^spjebifier skle4raitemen^est obllgatoirte ou^ptiome^ v est egalement mise\kn 




/ /\r OTSC * ue ce trart^me^.est35^a%ire et doit ainsketre execute) par 
fordinateuf client du resea^^^g^^i^une etape ^eW§rificatfonjE25 
permet/de verifier si le traiteMe^ du reseau 



ceuvre lors'de'cette etape'ie Wt=E24 6 >~\ 0 ' 



c , ^ 

En particular, I'o/dinateuKelieriV doit werifier si le 

r\\ \rr . ^v^=")]/y/|/ uz^xji , 

- ue"-(est bien implemente^par 



type de sjcrfpt 
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propose, viaj^dibri^^^ 

^on reitere^petfr|^ etapes5§ftest y 
JE23 a E25\ ' " " 7 ~ ' 

Sra^suede I'etape de verification E25/le^-a1tement < 6B^atoireyet 
executable par rocdhat^^n^s^pas^sup^ol^^ar celui-oi; y un" messlaqe 



yeclarantj^acces a I'operation -Jmpossible-gst ad resse A une etape de 
reponse E26 'a^o|dipateur client. 

^contrario.^tojs les traiteme^Qi^suppor^paT I'ordinateur 
client, a rissue^deTetape de te L st E23, lorsque toj^sHes^iternents ont ete 



analyses, une reponse-est^dresse^ dans une etape de 

reponse E27 indiquant que faeces a I'operation est possible. 

On va decrire a present en reference a la figure 3 un procede de 
validation d'un message recu par un ordinateur du reseau de communication. 
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Ce procede de validation d'un message permet a un noeud 
intermediaire du reseau, situe entre un emetteur et un recepteur d'un message, 
de valider le message comprenant des traitements. Cette validation du 
message est realisee grace a la connaissance d'un document de description 
d'un service WSDL tel que decrit precedemment. 

Ce noeud intermediaire du reseau de communication peut 
eventuellement effectuer des traitements. S'il n'effectue pas de traitement, il est 
adapte a verifier que I'ordinateur recepteur est capable d'effectuer les 
traitements sur le message envoye. Si ni le recepteur et ni le noeud 
intermediaire ne sont capables d'effectuer le traitement, I'ordinateur 
intermediaire peut eventuellement dinger le message vers un autre noeud du 
reseau de communication adapte a mettre en ceuvre le traitement. 

Si cet ordinateur intermediaire effectue des traitements, il verifiera si 
les donnees produites a 1'issue de ce traitement sont bien valides vis-a-vis du 
type de donnees affecte aux donnees tel que decrit dans le document de 
description WSDL conforme a invention. 

En pratique, une etape d'acquisition E30 du message est mise en 
ceuvre au niveau du nceud intermediaire. 

On identifie ensuite dans une etape d'extraction E31 la description 
du service associe grace a la lecture d'un document de description de service 
WSDL conforme a I'invention. 

On verifie dans une etape de test E32 s'il existe des traitements a 
effectuer. Dans la negative, une etape d'utilisation E33 est adaptee a utiliser le 
message des lors qu'il n'y a pas de traitement a realiser. Sinon, une etape 
d'extraction E34 permet d'extraire un traitement dans le message recu. 

Une etape de validation E35 est ensuite mise en ceuvre afin de 
valider le traitement par rapport a la description faite dans le document de 
description d'un service WSDL. 

En pratique on acquiert au moins une valeur imperative associee a 
une propriety du traitement telle que definie dans le message et on verifie dans 
une etape de verification si cette valeur imperative est bien incluse dans une 
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liste de valeurs attribuables a la propriete supportee par la fonctionnalite telle 
que decrite dans le document de description d'un service WSDL. 

Si a Tissue de cette etape de validation E35, le traitement n'est pas 
valide, une etape d'envoi E4 0 est adap tee a envoyer un message d'erreur a 
I'ordinateur client. 



'etape de validation 





si le traitement r est valide a Tissue 
>n oeciv^ ~ 




E35^nVetap^e, te^st(k^^tl\ra ( ise eiTc^^flrijide verifiehs^l^s'agit ou non 



dMn pre-traitement 

<^ Bn^ratiqu^orsj^Cce^^ 



une 



progry adap^e^sj^eeifier si le JaitemenresCfex^eute avankou^ap/es renvoi 
■ " rraessage^esMue^ 

Sycette valei|St ada^e^ s^ifier que^l^raitement doitetre 
execute'avant I'envoi du mb^sage^e^p^execution E37\^st alors^nise en^ 
ceuvre afin d'executer ce pre|telt]e^M< " 



/// Sin ° n ' Si * , ' iSSU l^ i ;^^^^\ va,eur 4 la\proprii^s1 
adaptee a ^m&^^^s^^^yM Peffelfexecute aprU I'envoLJu 
messade. on em. ^^^a^^^^^=^i!^^kSl&^ ~t loc Jtapes -E32-=4l 



mes'sige, ^^M^^^^^Sm^ et les 



suivantes 

\ \ \ j^' 
^4 message^ 

^alidatidr^E3 8^ pjN#pre 



un 'dags^le 



^^ernentN^ar^pport au type de donnees specifi^dapS le document 
description WSDhx 
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^ujn^tape-d^-^rEag^si^ette validatio 
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if 

&u non.@ris la negative, mtape«d'envorE40 d'un messaged 
ekuvre/^<| / . 

5inon, rens^l£"de§^^esp3p,j3u\vantes^e 
autre traiteme^nf^nccrpore dans le message "*"* 



On va decrire^a^esBXLtenrngference" a la figure 4 un procede de 
traitement d'un message comportant des traitements. 

Chaque message possede un contexte qui lui est associe. Ce 
contexte possede des informations de traitement non-incluses dans le 



reitere pour un 
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message. Par exemple, ces informations peuvent venir de messages 
precedents contenant des informations de traitement concernant le message. 

Une fois le message et son contexte acquis, on enumere les 
traitements. Chaque traitement est affecte au contexte (cree si necessaire) du 
message cible, ce message cible pouvant etre different du message contenant 
les informations de traitement. 

Ce contexte represente ainsi une liste ordonnee de traitements. 

Lorsque les traitements inclus dans le message ont ete enumeres 
on effectue Pensemble des traitements inclus dans le contexte, dans I'ordre 
specifie par le contexte. Apres avoir execute ce traitement, on valide les 
resultats en fonction du type de resultat attendu. Dans le cas d'une validation 
positive, on ajoute ces resultats au message. Lorsqu'il n'y a plus de traitement a 
effectuer, le message peut etre utilise, c'est-a-dire envoye ou traite comme un 
appel de fonction a distance. 

En pratique, une premiere etape d'acquisition E41 est mise en oeuvre 
afin de receptionner le message. Une etape d'acquisition E42 du contexte du 
message est egalement effectuee. On obtient ainsi la description de I'echange 
associe au message. On verifie ensuite dans une etape de test E43 s'il existe 
des traitements a effectuer sur le message. 

Dans ('affirmative, on extrait et on analyse I'ensemble de ces 
traitements. Ainsi, une etape d'acquisition E44 est mise en oeuvre afin d'obtenir 
le traitement suivant incorpore dans le message. Dans une etape d'extraction 
E45, le message cible est extrait du traitement et dans une etape d'ajout E46, le 
traitement est ajoute au contexte du message cible. 

Ainsi, ces differentes etapes E44 a E46 permettent d'entreposer 
dans le contexte du message cible I'ensemble des traitements a ajouter sur ce 
message. . 

Lorsqu'a Tissue de I'etape de test E43, it n'y a plus de traitement a 
effectuer sur le message, on verifie dans une etape de test E47 s'il existe des 
traitements a faire, tels qu'ils ont ete incorpores dans le contexte. 

S'il s'agit d'un traitement immediat des donnees du message on 
acquiert dans une etape d'acquisition E48 le traitement et on execute celui-ci. 
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Une etape d'extraction E49 permet d'extraire les resultats du 
traitement et de valider ces resultats en fonction des donnees types attendues a 
Tissue du traitement. 

Lorsque ces resultats sont valides, une etape d'integration E50 
permet d'integrer le resultat du traitement au message. 

On reitere les etapes de traitement E48 a E50 tant qu'il existe des 
traitements a effectuer dans le contexte. 

A Tissue de Tetape E47, lorsqu'il n'existe plus de traitement a realiser 
au niveau du noeud considere, les eventuels autres traitements devant etre 
effectues apres envoi du message par un autre ordinateur du reseau, ces 
traitements sont encodes comme information de la fonctionnalite et sont ajoutes 
au message. , 

Lorsqu'il n'y a plus de traitement, le message est utilise dans Tetape 
d'utilisation E51, c'est-a-dire que le message est envoye au noeud suivant dans 
le reseau de communication. 

On decrit ci-apres deux exemples d'encodage des informations d'une 
fonctionnalite qui sont introduites dans un message. Ainsi, on encode un 
traitement a effectuer dans un message, lors d'une interaction entre un .client et 
un serveur. Les valeurs des proprietes sont fixees et la fonctionnalite;.encode 
ces informations dans le message. 

Ces informations sont mises dans Ten-tete (en anglais "header") du 

message. 

< Soap : Envelope . ' . 

xnilns : Soap= n http : //schemas . xmlsoap . org/soap/envelope / " > 
<Soap : Header> 

<sf -.feature name= n XSLT_IN" id= ,, l" (msg=" self M 
,s,ide="receiver M ) 

xmlns : sf = ,? http : / /examples . com/soap/ProcessFeature" 

Soap: role="http: / /www . w3 .org/2 002 /0 6/soap- 

enve lope /role /next " 

Soap : mu st Understand=" true" > 

<sf:data> 

<input ref ="part : part 1 M /> 

<output ref="part: partl"/> 
</sf:data> 

<sf : processing type="XSLT n > 

<xsl : stylesheet version^" 1 . 0" 
xmlns : xsl="http : //v;ww . w3 . org/.../Transform"> 
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<xsl : template match="/ M > 

</xsl : template> 
</xsl : stylesheet> 
</sf : processing> 
</ sf : feature> 
</Soap : Header> 
<Soap : Body> 

<partl sf :name= ,T xsltin" sf:id="l"/> 
<part2> 

</part2> 
</Soap:Body> 
</Soap : Envelope> 

Dans cet exemple precedent, le message comporte un script a 
executer sur ce message a la reception. Ce script est du type XSL et va utiliser 
des donnees contenues dans la partie "parti" du message et !es remplacer par 
le resultat du script. 

Le schema des donnees en entree n'est pas donne, mais il pourrait 
etre ajoute via un attribut "type" de ['element "input". Le schema des donnees 
en sortie n'est pas donne explicitement mais il doit correspondre au schema 
decrit dans le document de description d'un service WSDL du service recevant 
le message. 

<Soap : Envelope 

xmlns : Soap="http : //schemas . xmlsoap . org/soap/envelope/"> 
<Soap:Header> 
<sf : feature 

xmlns : sf="http: //examples . com/soap/ProcessFeature" 

name="XSLT_OUT" id="l" msg=" f oolMsgOut " 
side= M sender" ~ y 

, , , Soa P: role="http: / /www . w3 . orcj / 2002 / 06 / soap- 
envelope/ role/ next" F 

Soap :mustUnderstand="t rue "> 

<sf : data> 

<input ref="part :partl"/> 
<output ref- u part:partl"/> 
</sf:data> 
. <sf .-processing type="XSLT"> 

<xsl : stylesheet version="l . 0" 
xmlns : xsl="http : //www . w3 . org/.../Transform"> 
<xsl : template match='7"> 

</xsl : template> 
</xsl : stylesheet> 
. , </sf :processing> 

</sf : feature> 
'</Soap:Header> 
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<Soap:Body> 

<partl sf :name="xsltin " sf : id= " 1 " /> 
<part2> 

</part2> 
</Soap: Body> 
</Soap : Envelope> 

Dans ce second exemple, le message comporte un script a executer 
sur un message "foolMsgOut" avant renvoi du message. Le script est 
egalement de type XSL et utilise les donnees contenues dans la-partie "parti" 
du message. Le traitement est adapte a remplacer ces donnees par le resultat 
5 du script 

Dans cet exemple, le, noeud qui regoit le message va stocker 
reformation et I'utiliser correctement : s'il emet le message "foolMsgOut", il 
appliquera le script a ce message avant de I'envoyer. Sinon, il enverra les 
informations de traitement au noeud qui emettra le message "foolMsgOut". 

10 La presente invention permet ainsi de definir un moyen de 

description d ! un service qui permet de decrire les pre-traitements et les post- 
traitements que le service peut effectuer. 

Afin de mettre en ceuvre le procede de proposition d'un service tel 
que decrit precedemment en reference a la figure 1 , un dispositif de proposition 

15 d'un service comprend essentiellement des moyens d'envoi d'un document de 
description d'un service comprenant une description d'une fonctionnalite mise 
en oeuvre lors d'un pre-traitement ou d f un post-traitement de donnees en format 
XML d'un message echange lors de Texecution du service sur ie reseau de 
communication. 

20 ^ De meme, un dispositif de test d'acces par un ordinateur client d'un 

reseau de communication comprend essentiellement des moyens d'extraction 
d'une description d'une fonctionnalite mise en oeuvre lors d'un pre-traitement ou 
du post-traitement de donnees en format XML d'un message echange lors de 
I'execution d'un service sur le reseau de communication, des moyens de lecture 

25 de la valeur associee a une propriete adaptee a specifier le noeud du reseau de 
communication adapte a executer le traitement et de la valeur d'une propriete 
adaptee a specifier si le traitement est obligatoire ou optionnel, et des moyens 
de verification si le traitement est supporte par I'ordinateur client du reseau de 
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communication lorsque le traitement est obligatoire et doit etre execute par 
I'ordinateur client du reseau de communication. 

Enfin, un dispositif de validation d'un message par un ordinateur 
intermediate d'un reseau de communication comprend des moyens d'extraction 
d'un traitement dans le message recu, des moyens d'acquisition d'au moins une 
valeur imperative associee a une propriete du traitement et des moyens de 
verification adaptes a verifier si la valeur imperative est incluse dans une liste 
de valeurs attribuables a une propriete supportee par la fonctionnalite decrite 
dans le document de description d'un service. 

Ces dispositifs de proposition d'un service, de test d'acces a un 
service et de validation d'un message peuvent etre incorpores dans un 
ordinateur tel qu'illustre a la figure 5. 

En particulier, le dispositif de proposition d'un service est incorpore 
dans un ordinateur serveur S d'un reseau de communication alors que le 
dispositif de test d'acces a un service est incorpore dans un ordinateur client C 
d'un reseau de communication. 

Plus precisement, les differents moyens identifies ci-dessus peuvent 
etre incorpores dans un microprocesseur 100, une memoire morte 101 ("Read- 
only memory" ou ROM) etant adaptee a memoriser un programme de 
proposition d'un service et/ou de test d'acces a un service et/ou de validation 
d'un message. 

Bien entendu, ces dispositifs de proposition d'un service, de test 
d'acces ou de validation d'un message peuvent etre mis en ceuvre dans un 
meme ordinateur ou bien dans des stations differentes du reseau de 
communication. 

Une memoire vive 102 ("Random access memory" ou RAM) est 
adaptee a memoriser dans des registres les valeurs modifiees lors de 
I'execution du programme de proposition d'un service, ou de test d'acces a un 
service ou de validation d'un message. 

Le microprocesseur 100 est integre a un ordinateur qui peut etre 
connecte a differents peripheriques et a d'autres ordinateurs d'un reseau de 
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communication 10. En particulier, cet ordinateur correspond a un ordinateur 
serveur S ou un ordinateur client C de ce reseau de communication 10. 

Cet ordinateur S, C comporte de maniere connue une interface de 
communication 110 reiie au reseau de communication pour recevoir ou 
transmettre des messages. 

L'ordinateur comporte en outre des moyens de stockage de 
documents, tel qu'un disque dur 106, ou est adapte a cooperer au moyen d'un 
lecteur de disque 107 (disquettes, disques compacts ou cartes infprmatiques) 
avec des moyens de stockage de documents amovibles, tels que des.disques 
7. Ces moyens de stockage fixes ou amovibles peuvent comporter le code des 
procedes conformes a I'invention. 

lis sont egalement adaptes a memoriser un document electronique 
de description d'un service tel que defini par la presente invention. 1 

A titre de variante, le programme- permettant au dispositif ■ de 
proposition d'un service, de test d'acces ou de validation d'un message peut 
etre stocke dans la memoire morte 101. 

En seconde variante, le programme pourra etre regu pour etre stocke 
comme decrit precedemment par Tintermediaire du reseau de communication 
10. 

L'ordinateur S, C possede egalement un ecran 103 permettant? par 
exemple de servir d'interface avec un operateur a I'aide du clavier 104 ou de la 
souris 105 ou de tout autre moyeh. 

L'unite centrale 100 (CPU) executera alors les instructions relatives a 
la mise en oeuvre de I'invention. Lors de la mise sous tension, les programmes 
et methodes relatives a I'invention stockes dans une memoire non volatile, par 
exemple la memoire 101, sont transferes dans la memoire 102 qui contiendra 
alors le code executable de Hnvention ainsi que les variables necessaires a la 
mise en oeuvre de I'invention. • • 

Le bus de communication 112 permet la communication entre les 
differents sous-elements de l'ordinateur ou lies a lui. 
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La representation de ce bus 1 12 n'est pas limitative et notamment le 
microprocesseur 100 est susceptible de communiquer des instructions a tout 
sous-element directement ou par I'intermediaire d'un autre sous-element. 

Bien entendu, de nombreuses modifications peuvent etre apportees 
aux exemples de realisation decrits precedemment sans sortir du cadre de 
invention. 
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REVENDICATIONS 

1. Procede de proposition d'un service fourni par un ordinateur 
serveur dans un reseau de communication, caracterise en ce qu'il comprend 
une etape d'envoi (E11) d'un document de description d'un service comprenant 
une description d'une fonctionnalite mise en oeuvre lors d'un pre-traitement ou 
d'un post-traitement de donnees en format XML d'un message echange lors de 
^'execution dudit service sur le reseau de communication. 

2. Procede de proposition d'un service conforme a la revendication 

1, caracterise en ce que ladite fonctionnalite definit des traitements adaptes a 
produire ou utiliser des donnees en format XML definies dans une premiere 
partie abstraite de document de description d'un service. 

3. Procede de proposition d'un service conforme a la revendication 

2, caracterise en ce que la description de ladite-fonctionnalite est inseree dans 
ladite premiere partie abstraite du document de description d'un service. S 

4. Procede de proposition d'un service conforme a Tune des 
revendications 1 a 3, caracterise en ce que ledit pre-traitement ou ledit post- 
traitement est mis en oeuvre via un langage de script. ;i 

5. Procede de proposition d'un service conforme a rune'; des 
revendications 1 a 4, caracterise en ce que ladite fonctionnalite est definie 
comme une donnee en format XML dans une premiere partie abstraite de 
document de description d'un service. 

6. Procede de proposition d'un service conforme a la revendication 
5, caracterise en ce que ladite donnee en format XML definissant ladite 
fonctionnalite est encodee dans une seconde partie concrete du document de 
description d'un service. 

7. Procede de proposition d'un service conforme a Tune des 
revendications 1 a 6, caracterise en ce que la description de ladite 
fonctionnalite comprend une liste de proprietes supportees par ladite 
fonctionnalite, lesdites proprietes definissant au moins respectivement : 

le nceud du reseau de communication adapte a executer ledit 

traitement ; et 
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le type de traitement. 

8. Procede de proposition d'un service conforme a la revendication 
7, caracterise en ce que ladite fonctionnalite comprend en outre une propriete 
adaptee a specifier si ledit traitement est effectue a ('envoi ou a la reception 
dudit message. 

9. Procede de proposition d'un service conforme a I'une des 
revendications 7 ou 8, caracterise en ce que ladite fonctionnalite comprend en 
outre une propriete adaptee a specifier le message ou un ensemble de 
messages sur lequel s'applique ledit traitement. 

10. Procede de proposition d'un service conforme a I'une des 
revendications 7 a 9, caracterise en ce que ladite fonctionnalite comprend en 
outre une propriete adaptee a definir les donnees produites ou utilisees par ledit 
traitement, et eventuellement le type desdites donnees. 

11. Procede de proposition d'un service conforme a I'une des 
revendications 7 a 10, caracterise en ce que la description de ladite 
fonctionnalite comprend une propriete adaptee a specifier si le traitement a 
effectuer est obligatoire ou optionnel. 

12. Procede de proposition d'un service conforme a I'une des 
revendications 7 a 11, caracterise en ce que pour au moins une propriete 
supportee par ladite fonctionnalite, la description de ladite fonctionnalite 
comprend une liste de valeurs attribuables a ladite propriete. 

13. Procede de test d'acces a un service par un ordinateur client 
d'un reseau de communication, a partir d'un document de description d'un 
service, caracterise en ce qu'il comprend les etapes suivantes : 

- extraction (E23) d'une description d'une fonctionnalite mise en 
oeuvre lors d'un pre-traitement ou du post-traitement de donnees en format 
XML d'un message echange lors de ('execution dudit service sur le reseau de 
communication ; 

- lecture (E24) de la valeur associee a une propriete adaptee a 
specifier le nceud du reseau de communication adapte a executer ledit 
traitement ; 
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lecture (E24) de la valeur d'une propriete adaptee a specifier si 
ledit traitement est obligatoire ou optionnel ; et 

verification (E25) si ledit traitement est supporte par I'ordinateur 
client du reseau de communication lorsque ledit traitement est obligatoire et doit 
etre execute par ledit ordinateur client du reseau de communication. 

14. Procede de validation d'un message regit par un ordinateur 
interrn^diaire du reseau de cgmmunication^ a partir d'un document, de 
description d'un service comprenant une description d'une fonctionnalite mise 
en oeuvre lors d'un pre-traitement ou du post-traitement de donnees en format 
XML du message echange lors de I'execution d'un service sur le reseau de 
communication, caracterise en ce qu-.il comprend les etapes suivantes : 

- extraction (E34) d'un traitement dans ledit message regu ; 

acquisition (E35) d'au moins une valeur imperative associee a 
une propriete dudit traitement ; et - 

verification (E35) si ladite valeur imperative est incluse dans une 
liste de valeurs attribuables a une propriete supportee par ladite fonctionnalite 
decrite dans le document de description d'un service. 

15. Procede conforme a la revendication 14, caracterise en ce qu'il 
comprend en outre les etapes suivantes : * 

lecture (E36) de la valeur associee a une propriete adaptee a 
specifier si le traitement est execute avant ou apres I'envoi dudit message ; et 

execution (E37) dudit traitement lorsque ladite valeur est adaptee 
a specifier que le traitement doit etre execute avant renvoi du message. 

16. Dispositif de proposition d'un service fourni par un ordinateur 

serveur dans un reseau de communication, caracterise en ce qu'il comprend 

des moyens d'envoi (100, 101, 102) d'un document de description d'un service 

* . . " ■ ■ 

comprenant une description d'une fonctionnalite mise en oeuvre lors d'un pre- 

traitement ou d'un post-traitement de donnees en format XML d'un message 

echange lors de ('execution du service sur le reseau de communication. 

17. Dispositif de proposition d'un service conforme a la revendication 
16, caracterise en ce qu'il est incorpore dans : 

un microprocesseur (1 00) ; 
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- une memoire morte (1 01) adaptee a memoriser le programme de 
proposition d'un service ; et 

- une memoire vive (102) comportant des registres adaptes a 
memoriser des variables lors de la mise en ceuvre du programme. 

18. Dispositif de test d'acces a un service par un ordinateur client 
d'un reseau de communication, a partir d'un document de description d'un 
service, caracterise en ce qu'il comprend : 

- des moyens d'extraction (100, 101, 102) d'une description d'une 
fonctionnalite mise en ceuvre lors d'un pre-traitement du post-traitement de 
donnees en format XML d'un message echange lors de I'execution du service 
sur le reseau de communication ; 

- des moyens de lecture (100, 101, 102) de la valeur associee a 
une propriete adaptee a specifier le terminal du reseau de communication 
adapte a executer le traitement ; 

des moyens de lecture (100, 101, 102) de la valeur d'une 
propriete adaptee a specifier si le traitement est obligatoire ou optionnel ; et 

- des moyens de verification (100, 101 , 102) adaptes a verifier si le 
traitement est supporte par I'ordinateur client du reseau de communication 
lorsque ce traitement est obligatoire est doit etre execute par I'ordinateur client 
du reseau de communication. 

19. Dispositif de test d'acces conforme a la revendication 18, 
caracterise en ce qu'il comprend des moyens incorpores dans : 

un microprocesseur (100) ; 

- une memoire morte (101) adaptee a memoriser le programme de 
test d'acces ; et 

- une memoire vive (102) comprenant des registres adaptes a 
memoriser les variables modifiees lors de I'execution dudit programme. 

. 20. Dispositif de validation d'un message recu par un ordinateur 
intermediate du reseau de communication, a partir d'un document de 
description d'un service comprenant une description d'une fonctionnalite mise 
en oeuvre lors d'un pre-traitement ou du post-traitement de donnees en format 
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XML du message echange lors de I'execution d'un service sur le reseau de 
communication, caracterise en ce qu'il comprend : 

des moyens d'extraction (100, 101, 102) d'un traitement dans un 
message recu ; 

- des. moyens d'acquisition (100, 101, 102) d'au moins une valeur 
imperative associee une propriete du traitement ; et 

.-'>• - des moyens de verification (100, 101, 102) adaptes. a verifier si la 
valeur imperative est incluse dans une liste de valeurs attribuables a une 
propriete supportee par la fonctionnalite decrite dans le document de 
description d'un service. 

21. Dispositif de validation d'un message re$u conforme a la 
revendication 20, caracterise en ce qu'il comprend des moyens incorpores 
dans : 

un microprocesseur (100) ; 

une memoire morte (101 )_ adaptee a memoriser un programme 
de validation d'un message regu ; et 

- une memoire vive (102) comprenant des registres adaptes a 
memoriser des variables modifiees lors de I'execution dudit programme/ - 

22. Ordinateur serveur d'un reseau de communication, caracterise 
en ce qu'il comprend des moyens adaptes a mettre en oeuvre le procede de 
proposition d'un service conforme a Tune des revendications 1 a 12. 

23. Ordinateur client d'un reseau de communication, caracterise en 
ce qu'il comprend des moyens adaptes a mettre en oeuvre le procede de test 
d'acces conforme a la revendication 13. 

24. Ordinateur d'un reseau de communication, oaracterise en ce qu'il 
comprend des moyens adaptes a mettre le procede de validation d'un message 
conforme a Tune des revendications 14 ou 15. 

25. Reseau de communication, caracterise en ce qu'il comprend des 
moyens adaptes a mettre en oeuvre le procede de proposition d'un service 
conforme a Tune des revendications 1 a 12. 
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26. Reseau de communication, caracterise en ce qu'il comprend des 
moyens adaptes a mettre en oeuvre le procede de test d'acces conforme a la 
revendication 13. 

27. Reseau de communication, caracterise en ce qu'il comprend des 
moyens adaptes a mettre le procede de validation d'un message conforme a 
Tune des revendications 14 ou 15. 

28. Moyen de stockage d'informations, eventuellement totalement ou 
partiellement amovible, lisible par un systeme informatique, caracterise en ce 
qu'il comprend des instructions pour un programme informatique adaptees a 
mettre en oeuvre le procede de proposition d'un service conforme a I'une 
revendications 1 a 12 lorsque ce programme est charge et execute par le 
systeme informatique. 

29. Moyen de stockage d'informations, eventuellement totalement ou 
partiellement amovible, lisible par un systeme informatique, caracterise en ce 
qu'il comprend des instructions pour un programme informatique adaptees a 
mettre en oeuvre le procede de test d'acces conforme a la revendication 13, 
lorsque ce programme est charge et execute par le systeme informatique. 

30. Moyen de stockage d'informations, eventuellement totalement ou 
partiellement amovible, lisible par un systeme informatique, caracterise en ce 
qu'il comprend des instructions pour un programme informatique adaptees a 
mettre en oeuvre le procede de validation d'un message conforme a I'une des 
revendications 14 ou 15, lorsque ce programme est charge et execute par le 
systeme informatique. 

31. Programme d'ordinateur lisible par un microprocesseur, 
caracterise ce qu'il comprend des portions de code logiciel adaptees a mettre 
en ceuvre le procede de proposition d'un service conforme a ['un des 
revendications 1 a 12, lorsque ce programme d'ordinateur est charge et 
execute par le microprocesseur. 

32. Programme d'ordinateur lisible par un microprocesseur, 
caracterise ce qu'il comprend des portions de code logiciel adaptees a mettre 
en oeuvre le procede de test d'acces conforme a la revendication 13, lorsque ce 
programme d'ordinateur est charge et execute par le microprocesseur. 
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33, Programme d'ordinateur lisible par un microprocesseur, 
caracterise ce qu'il comprend des portions de code logiciei adaptees a mettre 
en oeuvre le procede de validation d'un message conforme a Tune des 
revendications 14 ou 15, lorsque ce programme d^rdinateur est charge et 
execute par le microprocesseur. 
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